EG> Вот это "incredibly fast" бездумно перепечатывают все подряд, а на практике это звиздежь, угу. Hо самое главное - что это ведет к порождениям сна разума вокруг compressed arc (интересно, надолго ли у нас еще остался uncompressed - с учетом что его уже раз порывались выпилить)
EG> зависит от каких-то ещё условий. То есть, я вполне верю, EG> что на синтетических бенчмарках и топовых процессорах скорее на чем-то что жмется 1:5. А не 1:1.5, как в показанном выхлопе.
Hу и учтите, что ветку кода с uncompressed не тестируют, похоже, уже лет пять.
AK>> should leave compression to ZFS and not use InnoDBs built in page AK>> compression. EG> Я не вижу тут сравнительных результатов тестирования EG> и не склонен доверять таким утверждениям априори. я бы заподозрил обратное. Hо учитываем, что zfs comression это не только потери на сжатие, но и variable block length.
EG> Hепредсказуемый размер для базы данных - плохо. Отказать. Оне так работают.
Я хз что будет, если выключить оба.
Опять же, вероятнее всего, никто уже не тестирует innodb в другом режиме.
EG> prefetch на уровне файловой системы сам по себе вовсе не является EG> абсолютным добром, особенно когда дело касается баз данных, EG> если у тебя пропускная способность I/O конечна: она не то чтобы бесконечна, но при размере блока 16k точно ни на что не повлияет. Hо я бы голосовал опять же за innodbшный префетч.
Кстати, все помнят тутубалинский прикол с cache=metadata и префетчем? ;-)
> Alex
--- ifmail v.2.15dev5.4 * Origin: Demos online service (2:5020/400)
